I don't think this explanation is the full story, but generally agree this needs an update. The issue I have with the fix is that the GDAL/ArcGIS parameter is called MAX_Z_ERROR/Max-error not Precision. Which to me is different since precision is to what decimal place is the data stored, and max error, is how far is the value allowed to change from what's currently stored. Net effect is the same but explaining the number is different.

Precision would be a number like 3, but the equivalent max error would be .001?

https://kokoalberti.com/articles/geotiff-compression-optimization-guide/

cc: @vincentsarago

@wildintellect I completely agree there is a jumbling of terms error vs precision, I originally had it as MAX_Z_ERROR but I thought that may be too GDAL specific and reworded it to precision as it was used earlier in the paragraph.

How about something like :

this compression is not lossless when used with an allowed error greater than zero.

Or going back to MaxZError as its referenced on https://github.com/Esri/lerc#when-to-use

this compression is not lossless when used with a MaxZError greater than zero.

I was also trying not to completely change the flow of this paragraph being as it is my first pull request.

This section could be changed further, LERC is quite good (fast compression/decompression & good output size) for most lossless applications I have tried, uint8 (RGBA), uint16(RGBi), float32(DEM/DSM). It also has a nice wasm interface for accessing raw pixel values in a browser.

@blacha feel free to propose alternate text.
Also just discovered thanks to @bitner , that you can check which Compression is available in GDAL with gdalinfo --format gtiff